What problem does this PR solve?

The subtask state machine and worker controller mechanisms are not ideal now.
Users use direct interaction to manipulate tasks, like user issue a create task request and the request fails, dm-worker wouldn't leave any information about it. the implementation is not conducive to debugging and make restoring tasks more difficult when dm-worker restarts. ref #77

What is changed and how it works?

• Introducing log in dm-worker to store task request
  • use leveldb as local kv db, store task meta and task operation log in it
  • wrap task operation log as a queue-like object, providing operation
    • peek oldest non-handled log
    • forward handled pointer and mark the result of this log
  • make DM-worker's communication framework asynchronous
    • DM-worker would return success while it store the request operation into log
    • a background goroutine worker/handleTask would apply these logs in order and mark it's result
    • add a waitOperationOk function for DM-server to make the asynchronous request be asynchronous
  • simplify subtask state machine
    • only leave Run, Close operations and make them reentrant

I try to keep the original code of subtask.go and worker.go, and we will further simplify them while improve the test coverage.
In fact because the code is too much, I think it's better to issue first edition firstly. Don't worry, most of them are unit test.

Some review concerns

• review the design and implement from multiple pointer
  • log
  • rpc interface
  • subtask state machine
  • worker controller
• some point are really different
  • asynchronous request - even we make the asynchronous request be synchronous, but in fact it's different with old fashion, the former takes effect more slowly. In some failpoint panic testing , we should change checking result way
  • there a lot of problems related to the use and release and of resources, I remove pause and resume function, it may affect some mechanisms like online ddl

Check List

Tests

• Unit test
• Integration test
• Manual test
  • start a dm cluster
  • start/pause/stop/resume task
• No code

Code changes

• Has interface methods change
• Has persistent data change

Side effects

• Breaking backward compatibility - we should upgrade dm-worker/master at the same time